Mobile device with scannable image including dynamic data

ABSTRACT

A mobile phone is disclosed. The mobile phone may receive a first request to generate an initial scannable image, and a second request to generate modified scannable image. The modified scannable image can include a static portion that corresponds to a static portion of the initial scannable image. The modified scannable image may also include another portion that has a different appearance than a corresponding portion of the initial scannable image.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No.62/035,694, filed Aug. 11, 2014, which is incorporated by reference inits entirety for all purposes.

BACKGROUND

QR codes have been used to encode access credentials (e.g., paymentcredentials such as a primary account number) to access a resource(e.g., goods or services at a merchant, access to an airplane, etc.). Insome cases, a QR code may be displayed on a user's phone well in advanceof the time that the user may actually use the QR code. When the QR codeis displayed in this manner, there is a chance that the QR code may bestolen by a third party and possibly used. For example, a user mayintend to use a QR code that is displayed on the user's phone and thatencodes a payment account number to pay for an item. The user may standin line waiting for his turn to pay at the merchant's POS terminal. Wellprior to arriving at the POS terminal, the user may have caused themobile phone to generate the QR code. While standing in line, the usermay be holding the mobile phone in a position (e.g., with the displayfacing outward from the user) that can allow an unauthorized person totake a picture of the QR code. Once the unauthorized person takes thepicture of the QR code, it is possible for the user to use the QR codeto make purchases with it. More secure ways of generating and using QRcodes, or other scannable images, are therefore needed.

Embodiments of the invention address this and other problems,individually and collectively.

BRIEF SUMMARY

Embodiments of the present invention relate to systems and methods forutilizing dynamic data in scannable images such QR codes to improve thesecurity associated with the use of such scannable images.

One embodiment of the invention is directed to a method comprisingreceiving, by a mobile device comprising a processor, and an inputelement and a display coupled to the processor, a first request for aninitial scannable image. The method also comprises generating, by themobile device, the initial scannable image, the initial scannable imagecomprising a first image portion comprising a static image and a secondimage portion associated with executable code. The method also includesreceiving a second request for a modified scannable image, and afterreceiving the second request, executing, by the mobile device, theexecutable code associated with the second image portion to form amodified second image portion. The method also includes displaying, by adisplay in the mobile device, the modified scannable image, the modifiedscannable image comprising the first image portion comprising the staticimage and the modified second image portion. The modified second imageportion in the modified scannable image has a different appearance thanthe second image portion in the initial scannable image.

Another embodiment of the invention is directed to a mobile devicecomprising a processor, a display coupled to the processor, and a memoryelement comprising code, executable by the processor, for implementing amethod. The method comprises receiving and an input element and adisplay coupled to the processor, a first request for an initialscannable image, generating the initial scannable image, the initialscannable image comprising a first image portion comprising a staticimage and a second image portion associated with executable code. Themethod also comprises receiving a second request for a modifiedscannable image, and after receiving the second request, executing theexecutable code associated with the second image portion to form amodified second image portion. The method also includes displaying, onthe display, the modified scannable image, the modified scannable imagecomprising the first image portion comprising the static image and themodified second image portion. The modified second image portion in themodified scannable image has a different appearance than the secondimage portion in the initial scannable image.

These and other embodiments of the invention are described in furtherdetail below.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a block diagram of a system according to an embodiment ofthe invention.

FIG. 2 shows a block diagram of some components of a mobile deviceaccording to an embodiment of the invention.

FIG. 3 shows a block diagram of some components of a wallet servercomputer according to an embodiment of the invention.

FIG. 4 shows a flow diagram of a method for conducting a paymenttransaction with a scannable image on a mobile device according to anembodiment of the invention.

FIG. 5 shows a mobile device displaying a request for input from a userto generate an initial scannable image according to an embodiment of theinvention.

FIG. 6A shows a mobile device displaying an initial scannable imageaccording to an embodiment of the invention.

FIG. 6B shows a mobile device with a prompt prior to generating amodified scannable image according to an embodiment of the invention.

FIG. 7 shows a mobile device displaying a modified scannable imageaccording to an embodiment of the invention.

FIG. 8 shows a block diagram of a computer apparatus according to anembodiment of the invention.

FIG. 9 shows a block diagram of a system that can use a mobile device toaccess a building.

DETAILED DESCRIPTION

One embodiment of the invention is directed to a method comprisingreceiving, by a mobile device comprising a processor, and an inputelement and a display coupled to the processor, a first request for aninitial scannable image. The initial scannable image may be in the formof a QR code. The method also comprises generating, by the mobiledevice, the initial scannable image. The initial scannable image maycomprise a first image portion comprising a static image and a secondimage portion associated with executable code. The method also includesreceiving a second request for a modified scannable image, and afterreceiving the second request, executing, by the mobile device, theexecutable code associated with the second image portion to form amodified second image portion. The method also includes displaying, by adisplay in the mobile device, the modified scannable image, the modifiedscannable image comprising the first image portion comprising the staticimage and the modified second image portion. The modified second imageportion in the modified scannable image has a different appearance thanthe second image portion in the initial scannable image.

A “mobile device” may include any suitable device that can be carried bya user. A mobile device may be mobile phone, keychain device, personaldigital assistant (PDAs), pager, tablet computer, laptop computer,wearable device (e.g., smart watches, fitness bands, jewelry, etc.), anautomobile with remote communication capability, a payment card, etc. Amobile device may also include a secure element that can be implementedin either hardware and/or software, which may store sensitive account orpersonal information.

A “scannable image” may include any suitable image that may be scannedto a scanner such as an optical scanner. Examples of scannable imagesmay be machine readable codes, which may be one or two-dimensional. Insome cases, a machine readable code is encoded using a Base64 encodingscheme. An example of a machine readable code may include a QR code,which may be made of a number of squares or modules. Some of thosesquares must not be covered or edited for the QR code to work correctly.The three large squares are the position markers which indicate thescanner where the edges of the code are. One or more smaller square arethe alignment markers that act as reference points for the scanner. Insome cases, alternating black and white modules are the timing patternsthat define the positioning of the rows and columns. Some sections ofthe code define the format, i.e., they indicate to the scanner whetherit is a website (URL), a text message, numbers, Chinese symbols or thecombination thereof. In some cases, a version number is marked by someof the modules. The amount of data that can be stored in a QR codedepends on the input character set, version and the error correctionlevel. As an example, up to 4296 alphanumeric characters may be storedin one QR code. QR codes can be created with built-in error correctionalgorithms that allow them to be scanned even if a few bytes aremissing, edited or covered. However, the storage capacity goes down withhigher error correction level. The number of bytes that can be editedmay be based on the version number. In some embodiments, a visibledesign may be embedded in the QR code utilizing the error correctionalgorithms to imply a seal of certification.

An “access device” may be any suitable device for communicating with amerchant computer or payment processing network, and for interactingwith a payment device, a user computer apparatus, and/or a user mobiledevice. An access device may generally be located in any suitablelocation, such as at the location of a merchant. An access device may bein any suitable form. Some examples of access devices include POSdevices, cellular phones, PDAs, personal computers (PCs), tablet PCs,hand-held specialized readers, set-top boxes, electronic cash registers(ECRs), automated teller machines (ATMs), virtual cash registers (VCRs),kiosks, security systems, access systems, Websites, and the like. Anaccess device may use any suitable contact or contactless mode ofoperation to send or receive data from, or associated with, a paymentdevice and/or a user mobile device. In some embodiments, where an accessdevice may comprise a POS terminal, any suitable POS terminal may beused and may include a reader, a processor, and a computer-readablemedium. A reader may include any suitable contact or contactless mode ofoperation. For example, exemplary card readers can include radiofrequency (RF) antennas, optical scanners, bar code readers, or magneticstripe readers to interact with a payment device and/or mobile device.

A “processor” may include a device that can process computer readablecode. An exemplary processor may be a central processing unit (CPU). Aprocessor can include a single-core processor, a plurality ofsingle-core processors, a multi-core processor, a plurality ofmulti-core processors, or any other suitable combination of hardwareconfigured to perform arithmetical, logical, and/or input/outputoperations of a computing device.

A “computer readable medium” (e.g., a non-transitory computer readablemedium) may comprise any suitable medium that can store computer code.It may store pure data such as account numbers or it may store computerexecutable code, which may be executed by a processor to accomplish anintended operation of a computer or device. Examples of computerreadable media include memory chips, memory sticks, disk drives, andother types of memory devices. Such memory devices may operate using anysuitable electrical, optical, electro-magnetic, etc. mechanism for datastorage.

An “authorization request message” may be an electronic message that issent to a payment processing network and/or an issuer of a paymentaccount to request authorization for a transaction. An authorizationrequest message according to some embodiments may comply with ISO 8583,which is a standard for systems that exchange electronic transactioninformation associated with a payment made by a consumer using a paymentdevice or a payment account. In some embodiments of the invention, anauthorization request message may include a payment token, an expirydate, a token presentment mode, a token requestor identifier, anapplication cryptogram, and assurance level data. The payment token mayinclude a payment token issuer identifier that may be a substitute for areal issuer identifier for an issuer. For example, the real issueridentifier may be part of a BIN (bank identification number) rangeassociated with the issuer. An authorization request message may alsocomprise additional data elements corresponding to “identificationinformation” including, by way of example only: a service code, a CVV(card verification value), a dCVV (dynamic card verification value), anexpiration date, etc. An authorization request message may also comprise“transaction information,” such as any information associated with acurrent transaction, such as the transaction amount, merchantidentifier, merchant location, etc., as well as any other informationthat may be utilized in determining whether to identify and/or authorizea transaction.

An “authorization response message” may be an electronic message replyto an authorization request message generated by an issuing financialinstitution or a payment processing network. The authorization responsemessage may include an authorization code, which may be a code that acredit card issuing bank returns in response to an authorization requestmessage in an electronic message (either directly or through the paymentprocessing network) to the merchant's access device (e.g. POS terminal)that indicates approval of the transaction. The code may serve as proofof authorization. As noted above, in some embodiments, a paymentprocessing network may generate or forward the authorization responsemessage to the merchant.

A “token” may include an identifier for a payment account that is asubstitute for an account identifier, such as a primary account number(PAN). For example, a token may include a series of alphanumericcharacters that may be used as a substitute for an original accountidentifier (e.g., a pseudo account number). For example, a token “49000000 0000 0001” may be used in place of a PAN “4147 0900 0000 1234.” Insome embodiments, a token may be “format preserving” and may have anumeric format that conforms to the account identifiers used in existingpayment processing networks (e.g., ISO 8583 financial transactionmessage format). In some embodiments, a token may be used in place of aPAN to initiate, authorize, settle or resolve a payment transaction orrepresent the original credential in other systems where the originalcredential would typically be provided. In some embodiments, a tokenvalue may be generated such that the recovery of the original PAN orother account identifier from the token value may not be computationallyderived. Further, in some embodiments, the token format may beconfigured to allow the entity receiving the token to identify it as atoken and recognize the entity that issued the token.

A “server computer” may typically be a powerful computer or cluster ofcomputers. For example, the server computer can be a large mainframe, aminicomputer cluster, or a group of servers functioning as a unit.

I. Exemplary Systems and Devices

FIG. 1 shows a system according to an embodiment of the invention. Thesystem may include a mobile device 102 that may be used at an accessdevice 112. The access device 112 may be a point of sale (POS) terminal.The access device 112 may be in communication with a merchant computer114 (or may be part of the merchant computer 114). The merchant computer114 may be in communication with an acquirer computer 116, a paymentprocessing network 118, and/or an issuer computer 120. A wallet servercomputer 104 may be in communication with the mobile device 102, theaccess device 112, the merchant computer 114, and the payment processingnetwork 118. The wallet server computer 104 could also be incommunication with the acquirer computer 116 and/or the issuer computer120 in other embodiments of the invention.

The computers, networks, and devices shown in FIG. 1 and describedherein may communicate using any suitable communications network.Suitable communications networks may be any one and/or the combinationof the following: a direct interconnection; the Internet; a Local AreaNetwork (LAN); a Metropolitan Area Network (MAN); an Operating Missionsas Nodes on the Internet (OMNI); a secured custom connection; a WideArea Network (WAN); a wireless network (e.g., employing protocols suchas, but not limited to a Wireless Application Protocol (WAP), I-mode,and/or the like); and/or the like.

Messages between the computers, networks, and devices may be transmittedusing a support secure communications protocols such as, but not limitedto, File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP);Secure Hypertext Transfer Protocol (HTTPS), Secure Socket Layer (SSL),ISO (e.g., ISO 8583) and/or the like.

The wallet server computer 104 may be a computer that manages a digitalwallet on behalf of the user of the mobile device 102. Further detailsregarding an exemplary wallet server computer 104 are provided belowwith respect to FIG. 3.

The access device 112 may be configured to interact with the mobiledevice 102, and may also be configured to generate an authorizationrequest message. The access device 112 may include an optical scannerthat can read a scannable image on a display of a mobile device.

The acquirer computer 116 may be a computer that is operated by anacquirer, which may maintain an account of a merchant operating themerchant computer 114. The acquirer computer 116 may be disposed between(in operational manner) the acquirer computer 116 and the issuercomputer 120.

The payment processing network 118 may include data processingsubsystems, networks, and operations used to support and deliverauthorization services, exception file services, and clearing andsettlement services. For example, the payment processing network 118 maycomprise a server computer, coupled to a network interface (e.g. by anexternal communication interface), and a database(s) of information. Anexemplary payment processing network may include VisaNet™. Paymentprocessing networks such as VisaNet™ are able to process credit cardtransactions, debit card transactions, and other types of commercialtransactions. VisaNet™, in particular, includes a VIP system (VisaIntegrated Payments system) which processes authorization requests and aBase II system which performs clearing and settlement services. Thepayment processing network 118 may use any suitable wired or wirelessnetwork, including the Internet.

The issuer computer 120 may be operated by an issuer. The issuer can bea bank and may hold an account of the user of the mobile device 102.

FIG. 2 shows a block diagram illustrating some components in anexemplary mobile device 102. The mobile device 102 may comprise aprocessor 102A and a computer readable medium 102B within a body (orouter casing) 102J. The body 102J may be in the form a plasticsubstrate, housing, or other structure. The computer readable medium102B could alternatively be detachable from the device (e.g. thecomputer readable medium 102B could comprise an external memory thatcould be connected through a physical interface such as a USBconnection, or the data could be hosted remotely and accessed wirelesslyby the device—e.g. the data could be hosted and stored at a remoterserver in the “cloud”).

The computer readable medium 102B may be in the form of a memory thatstores data. The memory may store information such as financialinformation, transit information (e.g., as in a subway or train pass),access information (e.g., access badges), serial numbers, mobile accountinformation, and any other suitable information. In general, any of thisinformation may be transmitted by the mobile device 102 to the accessdevice 112, via any suitable method, including the use of antenna 102Hor contactless element 102G.

In some embodiments, the mobile device 102 may further include acontactless element 102G, which is typically implemented in the form ofa semiconductor chip (or other data storage element) with an associatedwireless transfer (e.g., data transmission) element, such as an antenna.Contactless element 102G may be coupled to (e.g., embedded within) themobile device 102 and data or control instructions that are transmittedvia a cellular network may be applied to the contactless element 102G bymeans of a contactless element interface (not shown). The contactlesselement interface functions to permit the exchange of data and/orcontrol instructions between the mobile device circuitry and an optionalcontactless element 102G, or between another device having a contactlesselement (e.g. a POS terminal or a payment device). Contactless element102G may be capable of transferring and receiving data using a shortrange wireless communication capability. As noted above, mobile device102 may comprise components to both be the interrogator device (e.g.receiving data) and the interrogated device (e.g. sending data). Thus,the mobile device 102 may be capable of communicating and transferringdata or control instructions via both cellular network (or any othersuitable wireless network—e.g. the Internet or other data network) andshort range communications.

The processor 102A (e.g., a microprocessor) can be used for processingthe functions of the mobile device 102. A display 102D that is coupledto the processor 102A can allow a consumer to see phone numbers andother information and messages. The mobile device 102 may furtherinclude input elements 102E to allow a user to input information intothe mobile device 102, a speaker 102F to allow the user to hear voicecommunication, music, etc., and a microphone 1021 to allow the user totransmit her voice through the mobile device 102. The mobile device 102may also include an antenna 102H for wireless data transfer (e.g., datatransmission).

The mobile device 102 may also include a secure element 102C coupled tothe processor 102A. A secure element (SE) may include its own dataprocessor and memory and may be a tamper-resistant platform (typically aone chip secure microcontroller) capable of securely hostingapplications and their confidential and cryptographic data (e.g. keymanagement) in accordance with the rules and security requirements setforth by a set of well-identified trusted authorities. There can bethree different form factors of SE: Universal Integrated Circuit Card(UICC), embedded SE and microSD. Both the UICC and microSD areremovable.

In FIG. 2, the secure element 102C may comprise account credentials102C-1 and one or more encryption keys 102C-2. In other embodiments, asecure element 102C is not needed and the account credentials 102C-1 andthe one or more encryption keys 102C-2 may be securely stored in anormal memory device in the mobile device 102 or may be stored in aremote server (e.g., in the cloud). If they are stored on a remoteserver, they may be stored in a virtual secure element in someembodiments of the invention.

The computer readable medium 102B may include one or more softwaremodules and/or applications. For example, the computer readable medium102B may be a scannable image generation module 102B-1, a walletapplication 102B-2, a geo-location module 102B-3, and a timestamp module102B-4.

The scannable code generation module 102B-1 may comprise any suitablecomputer code, that when executed by the processor 102A, can generate ascannable image such as a QR code.

The wallet application 102B-2 may comprise any suitable software,executable by the processor 102A, that provides front end functionalityof the electronic wallet to the user. For example, the walletapplication 102B-2 may be embodied as a software applicationdownloadable by the mobile device 102. In some instances, the walletapplication 102B-2 may provide a user interface (such as a series ofmenus or other elements) that allows the user to manage his electronicwallet(s). In some embodiments, the wallet application 102B-2 may storedata in a computer readable memory for later use, such as userpreferences or identifiers associated with funding sources added to theelectronic wallet.

The geo-location module 102B-3 may comprise code, which when executed bythe processor 102A, can determine a location of the mobile device 102.The geo-location module 102B-3 may be part of a GPS device within themobile device 102 that can provide location data through a GPS process.It could alternatively determine a location using other means includingan IP address or signal strength from a nearby network node. Locationdata can be expressed in any suitable manner including latitude andlongitude, by zip code, by city, by address, street, etc.

The timestamp module 102B-4 may comprise code, which when executed bythe processor 102A, can determine the time and/or date at which anaction may be performed by the mobile device 102. The timestamp module102B-4 may work in conjunction with a clock (not shown) in the mobiledevice 102.

FIG. 3 shows a wallet server computer 104 comprising a processor 104Acoupled to a computer readable medium 104B. The computer readable medium104B comprises account data 104B-1, a validation module 104B-2, andencryption keys 104B-3. A network interface 104C may also be coupled tothe processor 104A.

The wallet server computer 104 may be programmed to provide some or allof the functionality associated with conducting transactions using anelectronic wallet, including maintaining an association between theuser's e-wallet and one or more payment accounts (such as a bank accountor credit card account). To provide electronic wallet services (i.e. theuse of the electronic wallet associated with a payment account toconduct a financial transaction), the wallet server computer 104 mayfurther provide a web interface (e.g. through one or more web pages) toreceive and transmit requests for payments services and/or may providean application program interface (API).

The account data 104B-1 may include information associated with theuser's payment accounts can be used in conducting a financialtransaction with a merchant. For example, account data 104B-1 maycomprise primary account numbers of one or more payment accounts (e.g.,payment accounts associated with a credit card, debit card, etc.) of theuser. In other embodiments, account data 104B-1 may include paymenttokens instead of account data.

The validation module 104 may work with the processor 104A to validatethe modified scannable image, and the functions performed are describedin detail below. It may utilize encryption keys 104B-3 and previouslystored account data 104B-1 to verify the data derived from a modifiedscannable image. Verification of the modified scannable image mayinclude determining if the modified scannable image was provided by therightful or authentic mobile device and/or user.

II. Exemplary Methods

A method according to the embodiments of the invention can be describedwith respect to FIGS. 1-6.

FIG. 4 shows a flow diagram illustrating a transaction process accordingto an embodiment of the invention.

Initially, a user (not shown) may operate a mobile device 102 and maywish to access a resource. For example, the user of the mobile device102 may want to pay for a good or service at a merchant operating theaccess device 112. Prior to arriving at the access device 112, the usermay launch the wallet application 102B-2 on the mobile device 102.

In step 1, once the wallet application 102B-2 is launched, the mobiledevice 102 may receive a first request for an initial scannable image(e.g., a QR code) from the user. The request for the initial scannableimage may take any suitable form. For example, the user may request thatthe mobile device 102 generate the initial scannable image by selectinga hardware or software button on the mobile device. Alternatively, theuser could provide an authentication credential such a biometric sample(e.g., a voice sample, an iris scan, a fingerprint) to the mobile device102 and this may constitute a request for an initial scannable image.

In some embodiments, transaction information may be provided to themobile device prior to receiving the request. The transactioninformation can include at least one of account identificationinformation (e.g., an account number and expiration date, or a paymenttoken), a transaction amount, a location from which the generatedscannable image was requested, a device that from which the generatedscannable image was requested, a merchant name, and a time at which thescannable image was requested.

The transaction information may have been provided to the mobile device102 in any suitable manner. For example, in some embodiments, at leastsome of the transaction information may be been received by the mobiledevice 102 from the access device 112, by the mobile device 102 throughuser data input (e.g., keying in an account number), and/or by themobile device 102 retrieving information from an internal memory orsecure element 102C. Some transaction information could also have beenadditionally or alternatively provided to the mobile device 102 over theair.

Illustratively, FIG. 5 shows a mobile wallet application 204 running ona mobile device 102. The mobile wallet application 204 may display orprovide input elements 314A, 314B to allow the user to interactivelyrequest and generate scannable images such as QR codes, or cancel thescannable image generation process. As shown in FIG. 5, prior togenerating the initial scannable image, transaction information 220 maybe displayed on the display of the mobile device 102. In otherembodiments, the transactional information 220 need not be displayed bythe mobile device 102 to the user. Some or all of the transactioninformation 220 may be encoded and/or encrypted in the subsequentlygenerated scannable images.

In order to carry out a transaction, the user initiates a first requestto the mobile wallet application 204 to generate an initial scannableimage (e.g., an initial QR code). The user may select one or more inputelements 314A (e.g., the “OK” button) to confirm the request to generatean initial scannable image. The user may initiate the generation of theinitial scannable image (e.g., initial QR code) in advance of thepurchase transaction or during the purchase transaction.

Also in step 1, after the request to generate the initial scannableimage is received by the mobile device 102, the mobile device 102 maygenerate the initial scannable image 308 as shown in FIG. 6A. Theinitial scannable image 308 may have been generated prior to a time thata user of the mobile device 102 actually presents the mobile device 102to the access device 112.

The initial scannable image 308 may be generated in any suitable manner.For example, the scannable image generation module 102B-1, inconjunction with the processor 102A, can generate the initial scannableimage 308 using data from various sources. For example, the scannableimage generation module 102B-1, in conjunction with the processor 102A,can retrieve data including the account credentials 102C-1 and theencryption keys 102C-2 from the secure element 102C, a geolocation ofthe mobile device 102 using the geo-location module 102B-3, and the timeof the request using the timestamp module 102B-4. This data and otherdata may be encoded using the scannable image generation module 102B-1and the processor 102A and converted into the initial scannable image308. Further details on how data such as this is used to generate theinitial scannable image 308 is provided below.

The initial scannable image 308 may comprise a first image portion 308A,a second image portion 308B, and a third image portion 308C. The first,second, and third image portions 308A, 308B, 308C may have any suitableshape and may occupy any suitable portion of the initial scannableimage.

The first image portion 308A may comprise a static image. The firstimage portion 308A may also be static in nature, in that the image doesnot change between the initial scannable image and a subsequentlygenerated modified scannable image. It may contain and encodetransaction data such as payment account data. Payment account data mayinclude a payment account number such as a credit card number (or apayment token), an expiration date, service code, and a verificationvalue such as a CVV, CVV2, DCVV, and DCVV2. Such information may havebeen previously stored in the secure element in the mobile device 102C.The first image portion 308A may also comprise information such as afirst name and last name of the user of the mobile device 102, as wellas a transaction amount. Such information may be in the clear, sincethis information can be used by a merchant or other party to process thetransaction.

The second image portion 308B can be dynamic in nature and may beassociated with executable code. It can be dynamic in the sense that theimage portion associated with it changes between the initial andmodified scannable images. The executable code may be stored on acomputer readable medium in the mobile device 102 and may cause theimage in the second image portion 308B to be modified. In the initialscannable image 308, the second image portion 308B may comprise noencoded data, or it may encode data similar to the data that isdescribed below in the third image portion 308C, but it may be in theclear instead of being encrypted. For example, in some embodiments,information such as the location of the mobile device 102 at the time ofthe initial request, the merchant name, information about the devicethat the initial scannable image is requested from, and informationabout the time of the initial request may be present in the second imageportion 308B. However, it may be in the clear instead of encrypted as inthe third image portion 308C. In other embodiments, the informationencoded in the second image portion 308B may be different than theinformation that is encrypted in the third image portion 308C. Forexample, the second image portion 308B might encode information such asa counter value, and the counter value may not be present in the thirdimage portion 308C.

The third image portion 308C may encode encrypted metadata. Theencrypted metadata may include information such as the location fromwhich the initial scannable image was requested, the device from whichthe initial scannable image was requested, the merchant name, and thetime the initial scannable image was requested, in encrypted form. Atleast some of the encrypted metadata (e.g., when the initial scannableimage was requested) may relate to a time, T1, when the request for theinitial scannable image 308 was made. Any suitable encryption algorithmincluding DES, triple DES, or AES may be used to encrypt the metadata.An encryption key (e.g., a symmetric encryption key) 102C-2 may be usedto encrypt the metadata. The third image portion 308C may also be staticin nature, in that the image does not change between the initialscannable image and a subsequently generated modified scannable image.

As shown in FIG. 6B, after the initial scannable image 308 is generated,the mobile device 102 may prompt the user to express an intent toactually use the initial scannable image 308 to pay for a good orservice. The prompt take any suitable form including a sound or othercommunication that signals to the user that the user needs to confirmuse of the scannable image to conduct the transaction. In someembodiments, as shown in FIG. 6B, an overlay 312 which states “Click OKto use QR code” can be shown on the mobile device 102. The initialscannable image 308 may not be used until the user confirms his intentto use the scannable image. As noted above, the use of asemi-transparent or transparent overlay can prevent the use of theinitial scannable image from being used. After the user selects theinput element 314A labeled “Ok,” the overlay may be removed as shown inFIG. 7.

At step 2, the user may receive a request for payment from the accessdevice 112. This may simply be a message that is displayed to the userto have the access device 112 scan a scannable image that is displayedon the mobile device 102. It may alternatively be a signal that is sentfrom the access device 112 to the mobile device 102.

At step 3, the mobile device 102 receives a second request for amodified scannable image from the user. The second request may besimilar to or different in nature than the first request.

After receiving the second request, the mobile device 102 executesexecutable code associated with the second image portion to form amodified second image portion. In some embodiments, the input element314A may be selected and this may execute the executable code on thecomputer readable medium in the mobile device 102. The mobile device 102then generates and displays, by a display in the mobile device, themodified scannable image 308′. For example, after selecting the inputelement 314A (OK button) shown in FIG. 6B, a modified scannable image308′ like the one shown in FIG. 7 is generated.

The modified scannable image 308′ comprises the first image portion308A, a modified second image portion 308B′, and the third image portion308C. The first image portion 308A in the modified scannable image 308′may have the same appearance as the first image portion in the initialscannable image 308. The modified second image portion 308B′ in themodified scannable image 308′ has a different appearance than the secondimage portion 308B in the initial scannable image 308. The third imageportion 308C in the modified scannable image 308′ may have the sameappearance as the third image portion 308C in the initial scannableimage 308. Although specific configurations are described, embodimentsof the invention are not limited to the specifically describedconfigurations. For example, the first image portion 308A could includeencrypted and/or dynamic data in addition to or instead of clear textdata.

The modified second image portion 308B′ may comprise dynamicinformation. Dynamic information encoded by the modified second imageportion 308B′ may include information regarding the location and timethat the modified scannable image is being used for the purchase, thedevice that the modified scannable image is generated on, and themerchant name. The dynamic information may relate to a subsequent time,T2, when the modified scannable image was requested. While the mobiledevice 102 that the initial scannable image is requested from and thedevice that the modified scannable image that is used for thetransaction are usually the same device, they may be separate devices inother embodiments of the invention.

As noted above, the modified second image portion 308B′ of the modifiedscannable image 308′ may contain a dynamic component that may changeover time (e.g., when the user is ready to use the mobile device toconduct a transaction). Once dynamic code associated with the secondimage portion 308B is executed, the executable code (e.g., Java script)generates output data, which results in an altered image in the modifiedsecond image portion 308B′. The altered image in the modified secondimage portion 308B′ may contain graphics or values that are differentfrom those of the second image portion 308B in the initial scannableimage 300 as a result of the alteration of the underlying data. Theexecutable code may alter or update information such as the locationthat the scannable image is being used, the device on which thescannable image resides, and/or the time the scannable image 308 isused. Dynamic data such as this may be verified by a remote servercomputer using data stored in the server computer or supplemental datareceived an authorization request message along with the barcode data.For example, the time that the modified scannable image 308′ was usedmay be compared with a time provided by an access device, and thesevalues may be compared by a remote server to authenticate thetransaction.

In other embodiments, the dynamic portion of the scannable image maysimply be a verification value (e.g., a dCVV) that changes for eachtransaction that is conducted. In such embodiments, the second imageportion 308B of the initial scannable image 308 may encode, with theimage, a verification value such as “457.” Once the executable code inthe modified scannable image portion 309 is executed, a counter or overvalue may be changed, and a new verification value such as “989” may beproduced as a result. The image portion that encodes a number such as“989” will have a different appearance than the image portion thatencode a number such as “457.” In other embodiments, the dynamic portioncould simply be the counter, which increments each time the executablecode is executed.

The changing information provided by the modified second image portion308B′ of the modified scannable image 308′ may bind the modifiedscannable image 308 to a single wallet application, since running thatcode in an application utilized by a third party will generate a staticimage instead of a dynamic one. Since the generated initial scannableimage in this case will not contain the updated altered image in themodified second image portion 308B necessary for authorization, thetransaction will be declined if it is used by an unauthorized party.

In some embodiments, after the modified scannable image 308′ is utilizedin a transaction, but the modified second image portion 308B′ may stayintact for a certain number of transactions. Yet, a limitation on thenumber of times the code can run may be set. For example, there may be alimitation in which the executable code can be executed five timesbefore it becomes invalidated and the user must stop using it.

At step 4, the access device 112 may scan the modified scannable image308′. The access device 112 may treat the payment token data as normalcard data and utilize the payment data and metadata read and decodedfrom the scannable image to generate a payment authorization requestmessage. The authorization request message may contain any of the dataencoded by the modified scannable image 308′. It may also includeinformation independently obtained or generated by the access device112. Such information might include a merchant ID, and a time stamp orgeo-location of the transaction (as generated and observed by the accessdevice 112).

At step 5, the access device 112 may send the authorization requestmessage to the wallet server computer 104, along with any other suitableinformation from the access device 112 (e.g., a merchant identifier orthe location of the access device 112). The wallet server computer 104may receive the payment data and metadata, which includes the encryptedmetadata and clear text metadata. It may also receive the dynamic dataencoded by the modified second image portion 308B′.

When the access device 112 sends the decoded information to the walletserver computer 104, it could, but need not be the form of a traditionalauthorization request message in a normal payment card transaction (anISO 8583 type message). For example, the authorization request messagemay be transmitted using a support secure communications protocols suchas, but not limited to, File Transfer Protocol (FTP); HyperText TransferProtocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), SecureSocket Layer (SSL), and/or the like.

At step 6, after receiving the decoded information from the accessdevice 112, the wallet server computer 104 may validate the receiveddata in the authorization request message. For example, in someembodiments, the received information may comprise the clear textinformation from the first image portion 308A, the clear text dynamicinformation from the second image portion 308B, and the encryptedmetadata from the third image portion 308C. The wallet server computer104 may then decrypt the encrypted metadata using an appropriateencryption key (e.g., a private key) 104B-3.

The validation of the received data may occur in any suitable manner.For example, if the location that the scannable image was requested from(encoded and encrypted in the third image portion) and the location thatthe scannable image was used (in the second image portion),significantly differ from each other, or significantly differs from thelocation of the access device 112, then the wallet server computer 104may determine that the transaction is not trustworthy since alllocations should match or correspond to each other. For example, if thelocation information from the third image portion and the second imageportion are Foster City, Calif. and Foster City, Calif., respectively,and the location information from the access device is San Francisco,Calif., then this may suggest that the modified QR code is not beingreceived from an authentic user or mobile device, because the locationof the access device should have been the same or similar to thelocation identified in the second image portion. In another example, ifthe location information from the third image portion and the secondimage portion are Foster City, Calif. and San Francisco, Calif.,respectively, and the timestamps associated with the third and secondimage portions are 12:00 pm and 12:05 pm, respectively, then themodified scannable image may be unverified or untrustworthy. In thiscase, it is possible that the initial scannable image was stolen inFoster City, Calif. (e.g., either through a hacked phone or by anunauthorized person surreptitiously taking a picture of it) and wassubsequently transmitted to another phone in San Francisco, Calif.

In another example, if the time that the scannable image was requestedfrom (encoded and encrypted in the third image portion) and the timethat the scannable image was used (in the second image portion),significantly differ from each other (e.g., a difference of over aweek), or significantly differs from the time obtained from the accessdevice 112, then the wallet server computer 104 may determine that thetransaction is not trustworthy since the different times shouldsubstantially match. On the other hand, if the time that the scannableimage was requested from (encoded and encrypted in the third imageportion) and the time that the scannable image was used (in the secondimage portion) match exactly, then this may indicate that the scannableimage was obtained by an unauthorized person, since the times shouldhave differed by a small amount (e.g., 10 minutes).

In yet other embodiments, the location and/or time of the mobile device102 during each of the scannable image generation requests may beobtained by the wallet server computer 104 through a differentcommunication channel (e.g., over a cellular network), and this locationand/or time data may be compared with location and/or time data receivedfrom the access device 112 to determine the authenticity of thetransaction.

In other embodiments, the modified scannable image 308B′ may beregenerated and compared with the received modified scannable image.Since the wallet server computer 104 already knows the encryptedmetadata and executable code associated with the user's walletapplication when it receives the modified scannable image, it mayregenerate scannable image based on that information. If the generatedscannable image matches the one that is received, then the wallet servercomputer 104 may verify the authenticity of the transaction.

After the modified scannable image 308′ is verified by the wallet servercomputer 104 and is determined to be from an authentic user and/ormobile device 102, the wallet server computer 104 could respond in anumber of ways. In some embodiments, if the modified scannable image308′ is not verified, then the wallet server computer 104 may simplyrespond with an authorization response message to the merchant computerdenying the transaction. In some embodiments, if the modified scannableimage 308′ is verified by the wallet server computer 104, then walletserver computer 104 may send an indicator to the access device 112indicating that the modified scannable image 308′ has been verified (orhas not been verified or has been determined to be untrustworthy). Thisindicator may then be included in any authorization request message thatis sent by the access device 112 to the issuer computer 120, via theacquirer computer 116 and the payment processing network 118. The issuercomputer 120 and/or the payment processing network 118 may then make adecision as to whether or not to authorize the transaction, or may usethe indicator as an input into their own fraud analysis process.

Assuming that the wallet server computer 104 does not make the finalauthorization decision and does not prevent the transaction from movingforward, at step 7, the wallet server computer 104 may forward thepayment authorization request message to the payment processing network118. Alternatively, the wallet server computer 104 may forward thepayment authorization request message to the access device 112, merchantcomputer 114, or acquirer computer 116, which may then forward it to thepayment processing network 118. The payment processing network 118 mayin turn forward the payment authorization request message to an issuercomputer 120 associated with the account being used to conduct thetransaction. The issuer computer 120 may decide whether or not toauthorize the transaction, and may then generate an authorizationresponse message and may send it back to the payment processing network118.

In some embodiments, the wallet server computer 104 may generate a newauthorization request message from the authorization request messagethat it received from the access device 112. This may be the case if theauthorization request message from the access device 112 to the walletserver computer 104 is in one data format (XML) and the authorizationrequest message transmitted by the wallet server computer 104 or by theaccess device 112 to the payment processing network 118 or issuercomputer 120 is in another data format (e.g., ISO 8583). Further, thenew authorization request message may have information that is bothcommon to and different from the information in the receivedauthorization request message and the new authorization request message.

At step 8, the payment processing network 118 may forward theauthorization response message containing information and send it to thewallet server computer 104. In other embodiments of the invention, theauthorization response message may be sent to the acquirer computer 116,and then to the access device 112 via the merchant computer 114.

At step 9, the wallet server computer 104 may send the paymentauthorization response to the access device 112.

At step 10, after the wallet server computer 104 receives theauthorization response message, the wallet server computer 104 may senda transaction completion message to the mobile wallet application 102B-2on the mobile device 102.

A clearing and settlement process between the issuer computer 120, theacquirer computer 116, and the payment processing network 118 may occurat a later time.

Although the above-described embodiments describes the verificationfunction being performed by the wallet server computer 104, in otherembodiments, the described verification functions could be performed onanother device or server computer (e.g., computers 114, 116, 118, or120).

Embodiments of the invention may provide a number of advantages. Forexample, embodiments of the invention may include a first scannableimage with an image portion that can change when the first scannableimage is converted to a second, modified scannable image. The second,modified scannable image is only generated at the point of sale. As aresult, it is difficult if not impossible for a fraudster to steal thesecond modified scannable image. Further, even if this was possible, thesecond, modified scannable image includes data that is dynamic so itwould not be used again or it may only be used for a very small numberof transactions, thereby limiting risk. Secondly, the modified scannableimage may include a portion with encrypted metadata that is relevant toa time T1 and another portion with dynamic data that is relevant to apoint in time T2. Two sets of data at different times may be used toverify that the modified scannable code and consequently the paymentaccount number or the payment token is being used by a legitimate mobiledevice. Thus, embodiments of the invention provide for a high level ofdata security when access to a resource is desired.

FIG. 8 is a high level block diagram of a computer system that may beused to implement any of the entities or components described above. Thesubsystems shown in FIG. 8 are interconnected via a system bus 800.Additional subsystems include a printer 808, keyboard 816, fixed disk818, and monitor 812, which is coupled to display adapter 810.Peripherals and input/output (I/O) devices, which couple to I/Ocontroller 802, can be connected to the computer system by any number ofmeans known in the art, such as a serial port. For example, serial port814 or external interface 820 can be used to connect the computerapparatus to a wide area network such as the Internet, a mouse inputdevice, or a scanner. The interconnection via system bus 800 allows thecentral processor 806 to communicate with each subsystem and to controlthe execution of instructions from system memory 804 or the fixed disk818, as well as the exchange of information between subsystems. Thesystem memory 804 and/or the fixed disk may embody a computer-readablemedium.

Embodiments of the invention can apply outside of the context of paymenttransactions. For example, FIG. 9 shows a block diagram of a buildingaccess system. FIG. 9 shows a mobile device 910 operated by a user 906.The mobile device 910 may generate the initial and modified scannableimages as described above, and the access device 920 may scan the imagesas explained above. Instead of the wallet server computer verifying themodified scannable image, the remote computer 940 in FIG. 9 can performa similar function. After the remote computer 940 verifies that themodified scannable image came from an authentic mobile device 910, theaccess device 920 may then proceed to let the user 906 enter thebuilding 930.

Any of the software components or functions described in thisapplication, may be implemented as software code to be executed by aprocessor using any suitable computer language such as, for example,Java, C++ or Perl using, for example, conventional or object-orientedtechniques. The software code may be stored as a series of instructions,or commands on a computer readable medium, such as a random accessmemory (RAM), a read only memory (ROM), a magnetic medium such as ahard-drive or a floppy disk, or an optical medium such as a CD-ROM. Anysuch computer readable medium may reside on or within a singlecomputational apparatus, and may be present on or within differentcomputational apparatuses within a system or network.

The above description is illustrative and is not restrictive. Manyvariations will become apparent to those skilled in the art upon reviewof the disclosure. The scope of the invention should, therefore, bedetermined not with reference to the above description, but insteadshould be determined with reference to the pending claims along withtheir full scope or equivalents.

One or more features from any embodiment may be combined with one ormore features of any other embodiment without departing from the scopeof the invention.

A recitation of “a”, “an” or “the” is intended to mean “one or more”unless specifically indicated to the contrary.

All patents, patent applications, publications, and descriptionsmentioned above are herein incorporated by reference in their entiretyfor all purposes. None is admitted to be prior art.

1.-19. (canceled)
 20. A method comprising: receiving, at a wallet servercomputer, data scanned from a scannable image displayed at a firstdevice during a transaction, wherein the scannable image comprises afirst image portion comprising a static image, a modified second imageportion comprising a first time when the scannable image was used, and athird image portion comprising a second time when the scannable imagewas requested; determining and comparing the first time and the secondtime from the scannable image; determining whether or not the first timeand the second time match; and generating an electronic communication todecline the transaction based on the step of determining whether thefirst time matches the second time exactly.
 21. The method of claim 20,wherein the wallet server computer is in communication with a mobiledevice of a user, an access device, a merchant computer, and a paymentprocessing network.
 22. The method of claim 20, wherein the walletserver computer manages an association between a digital wallet onbehalf of a mobile device of a user and one or more payment accounts ofthe user.
 23. The method of claim 20, wherein the first device is amobile device of a user.
 24. The method of claim 20, wherein thescannable image is a two-dimensional machine readable code.
 25. Themethod of claim 20, wherein the scannable image is scanned by an accessdevice.
 26. The method of claim 20, wherein the first image portionencodes a token.
 27. A wallet server computer comprising: a processor;and a memory comprising code, executable by the processor, forimplementing a method comprising: receiving data scanned from ascannable image displayed at a first device during a transaction,wherein the scannable image comprises a first image portion comprising astatic image, a modified second image portion comprising a first timewhen the scannable image was used, and a third image portion comprisinga second time when the scannable image was requested; determining andcomparing the first time and the second time from the scannable image;determining whether or not the first time and the second time match; andgenerating an electronic communication to decline the transaction basedon the step of determining whether the first time matches the secondtime exactly.
 28. The wallet server computer of claim 27, wherein thewallet server computer is in communication with a mobile device of auser, an access device, a merchant computer, and a payment processingnetwork.
 29. The wallet server computer of claim 27, wherein the walletserver computer manages an association between a digital wallet onbehalf of a mobile device of a user and one or more payment accounts ofthe user.
 30. The wallet server computer of claim 27, wherein the firstdevice is a mobile device of a user.
 31. The wallet server computer ofclaim 27, wherein the scannable image is a two-dimensional machinereadable code.
 32. The wallet server computer of claim 27, wherein thescannable image is scanned by an access device.
 33. The wallet servercomputer of claim 27, wherein the first image portion encodes a token.